According to Third Generation Partnership Project (3GPP) Technical Specification (TS) 33.203 V1.0.0 (Access Security for IP-based Services), the IMS (i.e. Internet Protocol (IP) Multimedia Core Network Subsystem or IP Multimedia Subsystem) in UMTS (Universal Mobile Telecommunications System) supports IP Multimedia applications such as conferencing using audio, video, and multimedia. 3GPP has chosen Session Initiation Protocol (SIP) as the signaling protocol for creating and terminating Multimedia sessions for wireless terminals, including mobile phones, laptop computers with a WLAN (wireless local area network) card and a USIM/ISIM (UMTS Subscriber Identity Module/IP Multimedia Private Identity), and other kinds of UE (user equipment). TS 33.203 sets out how a subscriber to IMS services is authenticated and how a subscriber authenticates the IMS, according to what is called IMS Authentication and Key Agreement (IMS AKA), which is patterned after the UMTS AKA set out in TS 33.102. (Every operator and even third parties can provide IMS services; thus not only is it necessary to authenticate that a user (i.e. the UE) is a subscriber, but it is also necessary to authenticate that the entity providing IMS services to the user is who it claims to be.)
Authentication allows each party to a communication to trust that the other is who it purports to be. A set of protocols, procedures, and associated agreements that allow communicating entities to trust that each is who it purports to be, so that keys that are used for digital signatures and encryption are genuine, is called a trust infrastructure.
All trust infrastructures ultimately rely on some information being provided “out-of-band,” i.e. on some transaction not susceptible to the eavesdropping that might occur in a communication using the trust infrastructure. The out-of-band information is typically a (public) key or keys associated with an identity (the identity of the owner of the key). For enabling a UTRAN to authenticate a user and vice versa, UMTS AKA relies on a private long-term key associated with the user, i.e. associated with the UMTS Subscriber Identity Module (USIM) in the UE operated by the user. The key is provided out-of-band to the USIM in the UE (when the USIM is manufactured) and is also provided out-of-band to a so-called authorization center (AuC), a facility that is part of the home environment for the user. The identity (of the USIM) to be associated with the key is of course provided along with the key, but authentication does not rely on keeping secret the identity associated with the private key.
Similarly, IMS AKA, in providing a trust infrastructure for accessing IM services via a mobile phone, uses a private long-term key exchanged out-of-band between an ISIM (IM Services Identity Module, playing a role analogous to that played by the USIM for general UMTS services) and an IM authorization center; the key is associated with an IP Multimedia Private Identity (IMPI) provided by the manufacturer of the USIM/ISIM (not necessarily the same as the manufacturer of the wireless terminal) and stored in the ISIM. The IMPI takes the form of a Network Access Identifier (NAI) as defined in IETF (Internet Engineering Task Force) RFC 2486.
Outside of the context of accessing IM services, authentication is sometimes performed using what is called a Public Key Infrastructure (PKI) as the trust infrastructure. A PKI makes use of what are called certification authorities (CAs) to issue so-called digital Certificates; because the Certificates are issued by a CA out-of-band to entities seeking to enable others to authenticate them, it is these digital certificates that are the out-of-band component of the trust infrastructure provided by PKI. Such Certificates provide for the secure distribution of Public Keys (for use in asymmetric key encryption), which in effect authenticates the participants in a communication (since the corresponding private keys can be used to digitally sign documents), i.e. the process of securely obtaining the public key of an entity is tantamount to authenticating the entity. To provide a basis for authentication and so for serving as an element of a trust infrastructure, a Certificate is a structured document that binds the name of a participant in a communication (or similar information) to a public key (the participant's public key), and is digitally signed by a CA, acting as a trusted third party. To verify a certificate, the user of the public key (sometimes called the relying party) must first obtain the public key of the CA by some other (out-of-band) trusted means. If this is done, and if the CA is able to certify the public key of other CAs, which in turn certify other CAs and so on, then an entity relying on the (trusted) CA will be able to securely communicate with any other entity for which there is a chain of certificates between the trusted CA and the CA certifying the key of the other entity.
A PKI includes not only a sufficiently interlinked network of CAs to ensure that any relying party can verify any given certificate, but also systems to issue and store certificates, to determine their authenticity, and to revoke certificates if keys become compromised, as well as possibly other services in connection with effectively utilizing public key cryptography and digital signatures, such as a non-repudiation service and a digital notary or digital time-stamping service. All of these services must work together and have a common understanding of the formats and protocols necessary to achieve their aims. It is the collection of these components that has come to be known as a PKI.
The so-called Transport Layer Session (TLS) Protocol, described in IETF RFC 2246, provides privacy and data integrity between two communicating applications, and more specifically for a client using Web-based services provided by a server, using hypertext transport protocol (HTTP); to provide privacy and data integrity, TLS uses a PKI (i.e. a PKI trust infrastructure) for authentication. The TLS Protocol is composed of two layers: the TLS Record Protocol and the TLS Handshake Protocol. The TLS Record Protocol is the lower layer, and is itself layered on top of some reliable transport protocol, such as the Transmission Control Protocol (TCP). The TLS Record Protocol provides connection security, and is used for encapsulation of various higher level protocols, one of which is the TLS Handshake Protocol. The TLS Handshake Protocol allows a server and client in a communication session to authenticate each other and to negotiate an encryption algorithm and cryptographic keys before the application protocol transmits or receives its first byte of data. The TLS Handshake Protocol provides connection security having three basic properties: the peer's identity can be authenticated using asymmetric, or public key, cryptography (e.g., RSA, DSS, etc.); the negotiation of a shared secret is secure in that the negotiated secret is unavailable to eavesdroppers, and for any authenticated connection the secret cannot be obtained, even by an attacker who can place himself in the middle of the connection; and the negotiation is reliable in that no attacker can modify the negotiation communication without being detected by the parties to the communication.
Because a large-scale PKI has yet to be implemented, and because of the complexity of such an infrastructure, it would be advantageous to use another trust infrastructure as a basis for authentication in the TLS Handshake Protocol.